I would actually much prefer if this function was left as it is, and jsonRpcResponses was implemented on top of it. This function is much more simple than jsonRpcResponses from an implementation point of view.

Having nextJsonRpcResponse be an implementation of jsonRpcResponses allow jsonRpcResponses to be more generic here, specifically stopping the iteration without having to throw an error (by returning { done: true }), whilst nextJsonRpc can still throw an error if there are no more responses (the chain is already removed), keeping backward compatibility.

But in saying that, that is the only benefit that I can think of though, I don't have too much of a strong opinion on this, let me know if you think otherwise and I'll revert this right away 🙏

Why remove the chain here?

I believe this behaviour make sense according to the documentation here. But I have removed it anyway, let me know what is your final judgement on this, thank you.

What about?

And turn jsonRcpResponses into a getter?

I have made this a readonly property. I think a property make more sense compared to a getter, because there's in fact only 1 iterable here:

• Each iteration yield the next value
• If multiple iterables are created and are iterated on, they will actually overlap (similar to call nextJsonResponse simultaneously)

What I meant by getter is to do get jsonRpcResponses() { return { next: ..., ... } }

Right, here I believe just a TypeScript readonly modifier is sufficient, like technically speaking other properties/methods like sendJsonRpc, nextJsonRpcResponse, etc are actually mutable as well. If you want to enforce immutability at runtime on the JS side, I think calling Object.freeze on the entire chain object is more effective.